Merge branch 'master' of ssh://git-annex.branchable.com

drain transferrer read handle when shutting it down

Fixes updating git index file after getting an unlocked file when
annex.stalldetection is set.

The transferrer may want to send additional protocol messages when it's
shut down. Closing the read handle prevented it from doing that, and caused
it to crash rather than cleanly shutting down.

Draining the handle without processing the protocol seemed ok to do,
because anything it outputs is going to be some side message displayed
at shutdown. Displaying those once per transferrer process that is running
seems unncessary.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

correct my comment

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

reproduced this now

reproduced this now

Merge branch 'master' of ssh://git-annex.branchable.com

Improved handling of --time-limit when combined with -J

When concurrency is enabled, there can be worker threads still running
when the time limit is checked. Exiting right there does not
give those threads time to finish what they're doing. Instead, the seeking
is wrapped up, and git-annex then shuts down cleanly.

The whole point of --time-limit existing, rather than using timeout(1)
when running git-annex is to let git-annex finish the action(s) it is
working on when the time limit is reached, and shut down cleanly.

I noticed this problem when investigating why restagePointerFile might
not have run after get/drop of an unlocked file. With --time-limit -J,
a worker thread may have finished updating a work tree file, and be killed
by the time limit check before it can run restagePointerFile. So despite
--time-limit running the shutdown actions, the work tree file didn't get
restaged.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

removed

Added a comment

Added a comment

Added a comment

Added a comment

comment

wording

comment

Merge branch 'master' of ssh://git-annex.branchable.com

annex.diskreserve default increased from 1 mb to 100 mb

It's hard to know what's a good default for this. But 1 mb seems way too
small, because it's very easy for a git pull or some similar operation
that we don't think of as using much space to use up 1 mb of space.

Most people would want to free up some space if a filesystem only had 100
mb free. But on a small VPS, it's probably not uncommon to have only 1 gb
free. So 1 gb is too large for annex.diskreserve.

While old 1 gb USB keys are around, it's unlikely that anyone is
relying on them to shuttle annex data around; it would be worth anyone's
time to upgrade to a 32 gb or larger cheap modern USB key ($5).

Sponsored-by: Kevin Mueller on Patreon

Added a comment

Added a comment

comment and todo

comment

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: "not inbackend=URL" is failed with parse error

Added a comment: "not inbackend=URL" is failed with parse error

Added a comment

initial report on odd "modified" status

Added a comment

Added a comment

wording

skip checkRepoConfigInaccessible when git directory specified explicitly

Fix a reversion that prevented git-annex from working in a repository when
--git-dir or GIT_DIR is specified to relocate the git directory to
somewhere else. (Introduced in version 10.20220525)

checkRepoConfigInaccessible could still run git config --list, just passing
--git-dir. It seems not necessary, because I know that passing --git-dir
bypasses git's check for repo ownership. I suppose it might be that git
eventually changes to check something about the ownership of the working
tree, so passing --git-dir without --work-tree would still be worth doing.
But for now this is the simple fix.

Sponsored-by: Nicholas Golder-Manning on Patreon

bug report rescued from forum

comment

comment

wontfix

comment

fixed

try retrieval from more than one export location when the first fails

Combined with commit 0ffc59d34107a3ee671b90fc7c59ca09c00abbf5, this
fixes the case where there are duplicate files on the special remote,
and the first gets modified/deleted, while the second is still present.

directory, adb: Fixed a bug when importtree=yes, and multiple files in the
special remote have the same content, that caused it to refuse to get a
file from the special remote, incorrectly complaining that it had changed,
due to only accepting the inode+mtime of one file (that was since modified
or deleted) and not accepting the inode+mtime of other duplicate files.

Sponsored-by: Max Thoursie on Patreon

change retrieveExportWithContentIdentifier to take a list of ContentIdentifier

This partly fixes an issue where there are duplicate files in the
special remote, and the first file gets swapped with another duplicate,
or deleted. The swap case is fixed by this, the deleted case will need
other changes.

This makes retrieveExportWithContentIdentifier take a list of allowed
ContentIdentifier, same as storeExportWithContentIdentifier,
removeExportWithContentIdentifier, and
checkPresentExportWithContentIdentifier.

Of the special remotes that support importtree, borg is a special case
and does not use content identifiers, S3 I assume can't get mixed up
like this, directory certainly has the problem, and adb also appears to
have had the problem.

Sponsored-by: Graham Spencer on Patreon

comment

comment

comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

deal with ignoreinode config setting

Improve handling of directory special remotes with importtree=yes whose
ignoreinode setting has been changed. (By either enableremote or by
upgrading to commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7.)

When getting a file from such a remote, accept the content that would have
been accepted with the previous ignoreinode setting.

After a change to ignoreinode, importing a tree from the remote will
re-import and generate new content identifiers using the new config. So
when ignoreinode has changed to no, the inodes will be learned, and after
that point, a change in an inode will be detected as a change. Before
re-importing, a change in an inode will be ignored, as it was before the
ignoreinode change. This seems acceptble, because the user can re-import
immediately if they urgently need to add inodes. And if not, they'll
do it sometime, presumably, and the change will take effect then.

Sponsored-by: Erik Bjäreholt on Patreon

comments

comment

improve wording

comment

comment

Added a comment

Added a comment

comment

vicfg: Include mincopies configuration

Sponsored-by: k0ld on Patreon

general purpose design for this todo

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

belated response

comment

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

closing

Added a comment

Added a comment

removed

Added a comment

Added a comment

Added a comment: My current use case

mention that whereis --all skips dead keys

I looked at all man pages with --all, and this was the only one that
needs to add this disclaimer. Others like get and drop obviously
won't operate on dead keys anyway, because a dead key does not have any
content located anywhere.

improve wording

comment

update to work with modern git

comment

comment

fix reversion on skipping dead keys in --all/bare

Fix a reversion that made dead keys not be skipped when operating on all
keys via --all or in a bare repo. (Introduced in version 8.20200720)

Also, improved the documentation of git-annex-dead, it does not only apply
to fsck --all.

Also, made git-annex fsck, when run on a file whose key is dead, display
that. Before, it displayed that only when run with --all, but with this
fix, it skips dead keys with --all. But it can still be run on a file that
uses a dead key, and displaying "This key is dead" explains to the user
why it does not consider missing content for it to be a problem.

Sponsored-by: k0ld on Patreon

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment

Added a comment: re: many small files

Added a comment: many small files

Merge branch 'master' of ssh://git-annex.branchable.com